Pull request overview

This PR improves the TrimmableTypeMap pipeline so Android components referenced only from a user-provided AndroidManifest.xml template are treated as unconditionally preserved, preventing them from being trimmed when there are no direct managed references.

Changes:

• Parse the manifest template for component declarations and mark matching scanned JavaPeerInfo entries as IsUnconditional.
• Integrate trimmable typemap generation more deeply into the MSBuild pipeline (targets + runtime host config), including generation of native typemap stub .ll sources.
• Expand scanning/generator models for manifest-related metadata and update tests for the updated JNI/native-callback naming behavior.

Reviewed changes

Copilot reviewed 36 out of 36 changed files in this pull request and generated 5 comments.

🤖 AI Review Summary

Verdict: ⚠️ Needs Changes

Found 2 issues (1 warning, 1 formatting):

• ⚠️ Formatting: Broken indentation in acwDirectory null-check block (TrimmableTypeMapGenerator.cs:66-68)
• 💡 API design: IsUnconditional changed from init to set — consider documenting the mutation contract

👍 Excellent test coverage — 6 new tests covering rooting, warnings, already-unconditional, empty manifest, relative names, and nested types. The ResolveManifestClassName logic correctly handles all three Android manifest name conventions (fully-qualified, dot-relative, simple).

Review generated by android-reviewer from review guidelines.

🤖 AI Review Summary

Verdict: ⚠️ Needs Changes

Found 1 issue:

• ❌ Bugs & correctness: RootManifestReferencedTypes() still skips <application android:name> and <instrumentation android:name>, so manifest-only entry points can still be trimmed away (src/Microsoft.Android.Sdk.TrimmableTypeMap/TrimmableTypeMapGenerator.cs:160).

The added coverage for relative and nested names is solid. Public CI is still pending, so I’m holding off on a ✅ until that and the manifest gap are addressed.

Review generated by android-reviewer from review guidelines.

🤖 AI Review Summary

Verdict: ⚠️ Needs Changes

Found 1 issue:

• ❌ MSBuild tasks: Bare Log.LogWarning without an XA code (GenerateTrimmableTypeMap.cs:99)

CI: The public dotnet-android check failure is an infrastructure agent-assignment abandonment, not caused by this PR's code. macOS build passed. Internal Xamarin.Android-PR is still running.

Positive callouts: The RootManifestReferencedTypes design is clean — keeping the lookup dictionary local to the method avoids any cross-call state pollution. The early-out on componentNames.Count == 0 is good. The ResolveManifestClassName logic correctly handles dot-prefix, bare (no-dot) names, and $-separated nested types. Mutation of IsUnconditional from init to set is safe: JavaPeerInfo is only ever stored as a list/dictionary value, never as a key, so hash-code mutation under a collection key cannot occur. The seven unit tests cover the happy path, relative names, nested types, already-unconditional types, empty manifest, unresolved types, and application/instrumentation types — solid coverage.

Review generated by android-reviewer from review guidelines.

🤖 AI Review Summary

Verdict: ⚠️ Needs Changes

I didn’t find any further code blockers after the latest follow-up fixes. The manifest-rooting, placeholder-resolution, and deferred-registration changes all look consistent, and the standalone typemap test suite is passing locally.

The remaining blocker is CI: the dotnet-android checks are still in progress, so this PR is not mergeable yet.

Found 1 suggestion:

• 💡 Testing — consider mirroring the new placeholder-rooting regression at the host-side MSBuild task layer as well, so the end-to-end GenerateTrimmableTypeMap wiring stays covered.

Review generated by android-reviewer from review guidelines.